home *** CD-ROM | disk | FTP | other *** search
/ SuperHack / SuperHack CD.bin / CODING / GRAPHICS / VOXRAY.ZIP / NOTES.TXT < prev    next >
Encoding:
Text File  |  1996-03-07  |  4.0 KB  |  87 lines
  1. New: The source now includes a makefile and a project file for Watcom C/C++.
  2. Compiles should be possible now.
  3.  
  4. The following are notes to the reviewing programmer.
  5. This program is spread out into several modules, many of which are
  6. themselves several files large. In general, for source code names
  7. which are not self-explanatory:
  8. a file prefix means it has to do with world file i/o
  9. a ray prefix either has to do with rendering or is from an
  10. older time when all files were ray prefixed
  11. a scr prefix means it has to do with screen management
  12. an spr prefix means it has to do with sprites/objects
  13. a vox prefix means it has to do with mountain rendering
  14.  
  15. Many of the sources are commented, but a few are not. In general, its not
  16. at all cryptic code. I've tried to adhere to the general philosophies of
  17. structured programming.
  18.  
  19. Important files:
  20.  
  21. gamerun.cpp - overall managing file. Runs almost everything
  22. dosrun.cpp - actual location of main() in DOS version. Just turns control
  23. over to gamerun.cpp
  24. rayinit.cpp - starts up and shuts down most system independent stuff
  25. raycast.cpp + bsptree.cpp - make up the meat of the overall renderer
  26. sprrend.cpp - the sprite renderer
  27. voxrend.cpp - c portion of mountain renderer
  28. filemain.cpp - overall managing file for world file i/o
  29. player.cpp - file that controls the player
  30. ray.h - info given to almost all files
  31. globals.h - global variables (I used to use globals, and now don't,
  32. but I still have relics)
  33. rayrend.h - h file for renderer
  34. rayfile.h - h file for world file i/o
  35. voxel.h - h file for mountain internal files
  36. voxinter.h - h for for mountain external files that want to use mountains
  37. sprutils.h + rayspr.h + rayspr.h - h files for sprites 
  38.  
  39. Command-line options:
  40.  
  41. -noshade turns off mountain shading
  42. -fastvox makes mountains render faster but not as nicely 
  43. (does not effect shading)
  44.  
  45. I haven't tried these in a long time, so I don't know if they work:
  46. -file uses alternate world file (will actually load DOOM wads too)
  47. -ftex use alternate world for floor textures
  48. -wtex same but for walls
  49.  
  50. A few idiosyncracies:
  51.  
  52. mix of the terms sprite and object- Technically, a sprite refers to a 
  53. specific type of object, on that rendered as a moving bitmap. However,
  54. in the program the terms are interchanged without concern for specific
  55. definition. When sprite is used, it sometimes refers specifically to the
  56. rendering of an object
  57.  
  58. #ifdef OS_ lines
  59. These refer to operating system dependent portions of the code.
  60. A windows port was actually written for the project, but unfortunately other
  61. aspects of the project to priority before I could debug the WINDOWS version.
  62. However, it actually compiled to windows at the time and ran, albeit in a
  63. slightly screwed up fashion(sp?) (the color palette was messed up). At this
  64. point, it probably will not compile cleanly to Windows, though finishing the
  65. port would require only a day or two for an experienced Windows programmer.
  66. (When I wrote the port, it was the first Win program I'd ever written).
  67.  
  68. code for objects & function pointers associated with them- The object model
  69. in the program is pretty neat. Rather than defining the object types at 
  70. compile time, object types are run-time defined in the world file. 
  71. Orchestrating this is not easy, and sometimes it makes object code overly 
  72. complex. However, it is interesting to note that you could now, for example,
  73. put the camera in eye of an enemy, or change one enemies pictures to change
  74. him form a human to a monster. You should also note that some of the later
  75. object code was written very close to the time a prototype was needed, as is
  76. as a result somewhat cryptic and inflexible.
  77.  
  78. the asm files
  79. sliver.asm- code for inner loop of rendering walls & floors
  80. voxrow.asm- one set of code for inner loop of mountains (partially shaded)
  81. voxrowf.asm- secode set of mountain code (no shading)
  82. vrsmooth.asm- final set of mountain code (full shading). This the one that is
  83. almost universally used
  84.  
  85. Sorry if I missed a bunch of stuff. I tried to put what I'd want to know
  86. if I had to look at my code.
  87.